-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update SIG Release charter to reflect latest changes #5409
Update SIG Release charter to reflect latest changes #5409
Conversation
This patch updates the SIG Release charter to reflect the current organizational structure. Signed-off-by: Sascha Grunert <sgrunert@suse.com>
/assign @justaugustus @LappleApple @hasheddan @alejandrox1 @jeremyrickard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/hold for @spiffxp to take a review pass
Thanks @saschagrunert!
@@ -14,10 +14,11 @@ This charter adheres to the conventions described in the [Kubernetes Charter REA | |||
- Ensuring quality Kubernetes releases | |||
- Defining and staffing release roles to manage the resolution of release blocking criteria | |||
- Defining and driving development processes (e.g. merge queues, cherrypicks) and release processes | |||
(e.g. burndown meetings, cutting beta releases) with the intent of meeting the release schedule | |||
(e.g. burndown meetings, cutting pre-releases) with the intent of meeting the release schedule | |||
- Managing the creation of release specific artifacts, including: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure this is really the place for it, but did want to call out that the original review that led to opening this issue requested more clarity on the specific binaries, tools, repos, and artifacts that fell under the purview of sig-release. There is a bit of a fuzzy line because almost everything sig-release releases is "owned" by another sig. I plan on having the specific artifacts better documented as part of kubernetes/sig-release#1337, but wanted to make sure @spiffxp knows that is not falling through the cracks.
ref #2919 (comment) and #2919 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having a specific list of artifacts better documented via kubernetes/sig-release#1337 satisfies most of my original concern. That said, #2919 (comment) still stands, I would like to see enumeration of what release-engineering owns, but that can also be done out-of-charter and linked
IMO there is overlap on driving development processes w/ SIG Architecture, SIG Contributor Experience and SIG Testing but I'm not concerned enough about the wording here to block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/cc @dims
for final approval as current @kubernetes/steering-committee liason
/approve please hold for additional steering reviewers. thanks for updating this! |
/lgtm |
/lgtm |
Thanks for the updates, Sascha! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, hasheddan, justaugustus, saschagrunert, spiffxp The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This patch updates the SIG Release charter to reflect the current
organizational structure.
Which issue(s) this PR fixes:
Closes kubernetes/sig-release#378
/cc @spiffxp @kubernetes/sig-release-leads